Strategies for Licensing on VMs
The diagram below displays a workflow of a one possible licensing strategy for VMs:
Below are few other possible licensing strategies for VMs:
| License Version | License Manager | Licensing Library | Outcome |
|---|---|---|---|
|
License Manager upgraded + License upgraded for new VM property |
|||
|
New v13 license with >Request on VM denied >Unlocked or any traditional locking criterion (other than CPU info) |
8.4.0 or later | Licensing libraries earlier than 8.4.0 |
Explicitly denies request by generating an unknown error. While choosing this option do take in account the inconvenience caused by denying the software use on a VM. Consider the following options as more moderate approaches on VMs. These are equally proactive in VM detection along with license enforcement. |
|
License Manager upgraded + License upgraded for new locking (single host VM) |
|||
|
New v13 license with >Request on VM allowed >CPU info + Ethernet address |
8.4.0 or later | Licensing libraries earlier than 8.4.0 | Does not explicitly deny requests. License requests per se are allowed to be served by the License Manager duplicated on a VM. However, since the locking criteria does not match for machines other than that line of CPUs, it will not be practically possible to misuse the license across License Managers on VMs. This enforces license agreement compliance through mismatched locking. |
|
License Manager upgraded + Licensed application upgraded calling new API |
|||
| Version older than v13 license with unlocked or any traditional locking criteria (other than CPU info) | 8.4.0 or later | 8.4.0 and the VLSisVirtualMachine API is called | The API will report whether or not the License Manager is running on a VM. You can decide any further action, like allowing or denying application use, differential pricing to allow use of application on VM, and so on. |